HPAVC

home *** CD-ROM | disk | FTP | other *** search

/ HPAVC / HPAVC CD-ROM.iso / pc / FAQSYS18.ZIP / FAQS.DAT / P16-FORM.TXT < prev next >

Wrap

Text File | 1996-01-04 | 19.7 KB | 358 lines

Below lists the format of the Protracker Studio 16 (PS16) header. This can change if it doesn't allow for enough flexibility for the time being. ╒══════════════════════════════════════════════════════════════════════════════╕ │ PS16 Header Format: │ ╘══════════════════════════════════════════════════════════════════════════════╛ Description Length Data Type Information ────────────────── ────── ───────── ───────────────────────────────────────── Sig 5 Character This contains the string "PS16■" which acts as both an identifier to determine the file, but also serves as part of the text string which can be done by TYPEing the file to the screen. SongName 75 Character This contains the 75-character name of the music file. This may contain the MODule name if converted from a MOD, or it may contain information on number of channels or whatever. The final byte, 75, MUST have a ^Z in it. TypeOfFile 1 Byte This field holds what type of music file the file is. If this field contains a 0, then it is a module with self-contained instruments. If it is a 1, then it is a song with the header and patterns, but not the samples. CommentOfs 4 Longint The Comment Offset field points to the offset of the file where comments begin. The comments contain all text and information pertinent to the music. The sample names are also stored here. See below for parsing information. This field DOESN'T need to be used. Just store a zero here if there are no comments. Version 1 Byte This is the version identifier for the PS16 file. All versions of PS16 formats will have the header structure as described thus far. The format from here on can change, although it isn't likely. The format described below is a Version 0 format. ──────────────────────────────────────────────────────────── Version 0 Header NumPatterns 1 Byte Contains the number of patterns (max 256) in the file. totalPatternSize 4 Longint For quick reads off the disk, the TOTAL pattern length is stored here. The maximum total size of patterns for any given music file is 3075 bytes per pattern * 256 patterns. With the current player, this is simply not possible. SongLen 1 Byte This contains the number of sequences in the PS16 file. Sequences 128 Byte These are the sequences for the entire PS16 music. Samples 31*PS16Sample These are the 31 individual sample structures, described below. ╒══════════════════════════════════════════════════════════════════════════════╕ │ PS16 Sample Header Format, Version 0: │ ╘══════════════════════════════════════════════════════════════════════════════╛ Description Length Data Type Information ────────────────── ────── ───────── ───────────────────────────────────────── BitStruc 1 Bit Field These are bits that may be set for each sample. The default for a MOD file is: Bit 0 - Digital, Bit 1 - 0, Bit 2 - 8-bit. 7 6 5 4 3 2 1 0 │ │ └─ 0 - Digital, 1 - Synthesized │ └─── (if bit 0=1) 0 - FM, 1 - Waveform └───── 0 - 8-bit, 1 - 16-bit. Volume 1 Byte Default volume for the sample. Range is 0 to 64 decimal. Please, ALWAYS make it default to this range. FineTune 1 Byte This field must contain one of the following values: 0 - Tuning 0 1 - Tuning 1 2 - Tuning 2 3 - Tuning 3 4 - Tuning 4 5 - Tuning 5 6 - Tuning 6 7 - Tuning 7 8 - Tuning -8 9 - Tuning -7 10 - Tuning -6 11 - Tuning -5 12 - Tuning -4 13 - Tuning -3 14 - Tuning -2 15 - Tuning -1 Length 4 Longint This contains the length of the sample. Currently, my player doesn't support greater than 64k samples, and I really don't see the need. It's here in case it's needed. Repeat 4 Longint This contains the repeat start for the sample. Again, this can be >64k RepeatLength 4 Longint This contains the repeat length for the sample. If the sample Length is greater than the sample Repeat plus the sample RepLen, then the sample can be clipped to Repeat+ RepLen. If you didn't get that, don't worry about it. C-2 Freq 2 Word The default playback frequency of a sample's C on octave 2. This can be used to fine tune a sample, but it defaults to 8448. ╒══════════════════════════════════════════════════════════════════════════════╕ │ PS16 Pattern Format, Version 0: │ ╘══════════════════════════════════════════════════════════════════════════════╛ Immediately following the version 0 header structure are the patterns. The reason that the offset of the patterns in the file is not contained in the header is because it was felt that the patterns would probably not be relocated. When converting from the MODule format, this format will always be a minimum of 253 bytes smaller than the patterns in a MODule. A MODule's pattern is always 1,024 bytes. This is obvious since a MODule note and effect occupies four bytes, and there are four channels per row. With 64 rows in a file, this equation becomes: 4 bytes * 4 channels * 64 rows = 1,024 bytes. A PS16 note occupies three bytes. A "note" in PS16 consists of the actual note, an instrument, and a special effect and its data. A PS16 note will use the following table to convert from Amiga periods to its own notes, and they will be stored as such: ┌─────┬─────┬─────┬─────┬─────┬─────┬─────┬─────┬─────┬─────┬─────┬─────┐ │ 1│ 2│ 3│ 4│ 5│ 6│ 7│ 8│ 9│ 10│ 11│ 12│ │ 1712│ 1616│ 1524│ 1440│ 1356│ 1280│ 1208│ 1140│ 1076│ 1016│ 960│ 906│ │ C-0│ C#0│ D-0│ D#0│ E-0│ F-0│ F#0│ G-0│ G#0│ A-0│ A#0│ B-0│ ├─────┼─────┼─────┼─────┼─────┼─────┼─────┼─────┼─────┼─────┼─────┼─────┤ │ 13│ 14│ 15│ 16│ 17│ 18│ 19│ 20│ 21│ 22│ 23│ 24│ │ 856│ 808│ 762│ 720│ 678│ 640│ 604│ 570│ 538│ 508│ 480│ 453│ │ C-1│ C#1│ D-1│ D#1│ E-1│ F-1│ F#1│ G-1│ G#1│ A-1│ A#1│ B-1│ ├─────┼─────┼─────┼─────┼─────┼─────┼─────┼─────┼─────┼─────┼─────┼─────┤ │ 25│ 26│ 27│ 28│ 29│ 30│ 31│ 32│ 33│ 34│ 35│ 36│ │ 428│ 404│ 381│ 360│ 339│ 320│ 302│ 285│ 269│ 254│ 240│ 226│ │ C-2│ C#2│ D-2│ D#2│ E-2│ F-2│ F#2│ G-2│ G#2│ A-2│ A#2│ B-2│ ├─────┼─────┼─────┼─────┼─────┼─────┼─────┼─────┼─────┼─────┼─────┼─────┤ │ 37│ 38│ 39│ 40│ 41│ 42│ 43│ 44│ 45│ 46│ 47│ 48│ │ 214│ 202│ 190│ 180│ 170│ 160│ 151│ 143│ 135│ 127│ 120│ 113│ │ C-3│ C#3│ D-3│ D#3│ E-3│ F-3│ F#3│ G-3│ G#3│ A-3│ A#3│ B-3│ ├─────┼─────┼─────┼─────┼─────┼─────┼─────┼─────┼─────┼─────┼─────┼─────┤ │ 49│ 50│ 51│ 52│ 53│ 54│ 55│ 56│ 57│ 58│ 59│ 60│ │ 107│ 101│ 95│ 90│ 85│ 80│ 75│ 71│ 67│ 63│ 60│ 56│ │ C-4│ C#4│ D-4│ D#4│ E-4│ F-4│ F#4│ G-4│ G#4│ A-4│ A#4│ B-4│ └─────┴─────┴─────┴─────┴─────┴─────┴─────┴─────┴─────┴─────┴─────┴─────┘ A zero is stored in the event a period was not found or approximated or when there is not an actual period being played. The note field requires 6 bits. Version 0 only handles 31 instruments. Thus, the instrument field requires 5 bits. The special effect field can range from 0 to F in hexadecimal and requires 4 bits. The special effects data field is a whole byte and can have 8 bits. Thus, with this information, we are able to construct the following bitfields: Byte 1 Byte 2 Byte 3 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 │ │ └─────────┘ └──┬──┘ └─────┘ └─────────────┘ │ │ Note │ Effect Effect Data │ └ Bit 5 of instrument └── Bits 1-4 of the instrument │ └── Follow previous line bit. Reconstruction algorithms are as follows: Get the ┌───Get Byte 1 Note └───AND it with binary 00111111b ┌───Get Byte 1 again. │ AND it with binary 01000000b │ Shift it right twice. Get the │ Store as result #1. Instr. │ Get Byte 2. │ AND it with binary 11110000b │ Shift it right four times. └───OR it with Result #1. Get the ┌───Get Byte 2 again. Effect. └───AND it with binary 00001111b Efx Data────Get Byte 3. Bit 7 requires a bit of additional explanation. As aforementioned, patterns can be a MINIMUM of 253 bytes smaller than their MOD counterparts. This is due to three special compression methods. One) Instead of ordering the patterns as Track 1, Track 2, Track 3, Track 4, then Track 1, Track 2 again and so on until the end, the Tracks are grouped together as all of Track 1 and all of Track 2 and so on. Two) If a note appears on row 0 and another note appears on row 5 with Three) nothing in between, why not get rid of the blank rows? For instance, a situation such as this may appear as: Module Track MOD Data PS16 Data 00 C-1 01 F06 0358 1F06 8D 1F 06 01 --- 00 000 0000 0000 02 --- 00 000 0000 0000 03 --- 00 000 0000 0000 04 --- 00 000 0000 0000 05 E-3 03 C40 00AA 3C40 05 29 3C 40 06 E-3 01 A01 00AA 1A01 A9 1A 01 07 --- 00 000 0000 0000 . . . . . . 63 --- 00 000 0000 0000 FF ──────────── ────────────── 1024 bytes 11 bytes Two and three are combined for two reasons. As can be seen, MODs store extra information for blank pattern lines. This was remedied in PS16 by two methods. If the jump between one line and another was greater than one, then the new line number was written out (see row 5 of the PS16 Data, first byte). However, if the two lines were right by each other (5 & 6), then the pattern row was not written out. Here's why. As you recall from the above diagrams of PS16 notes, it can be seen that Bit 7 is named "Follow Previous Line." This means that if the new PS16 line follows the previous line, there is no need to store a row number in front. All that needs be done is have this bit set. Let's break down the PS16 data from above: Row 0: 8D 1F 06 -- Bit 7 is set here. The first line of a pattern is always assumed to follow Byte 255 (which is what the line counter is initialized). A byte of 255 plus 1 = 0. Otherwise, the 0Dh in 8Dh specifies note 0Dh, which is C-1. The 1F 06 specifies instrument 1, special effect F (speed) 06. Row 5: 05 29 3C 40 -- Since there was a large skip here, and row 5 does not immediately follow row 0, the 5 was stored in first here. How does the interpreter know the difference between a row number and a note? A note ALWAYS follows a row number and if a row number is not present, then bit 7 MUST be set in the note. Bit 7 is NEVER set in a row except for the ONE exception below. Row 6: A9 1A 01 -- Immediately follows Row 5, so bit 7 is set. Final Byte: FF -- This is a -1 which means terminate track. A -1 always terminates the current track. Bear in mind that ALL 16 tracks are stored per pattern, so if converting from a MOD, tracks 5-16 are automatically set to -1. The discussion thus far has been centered around the general pattern format. Two other factors are introduced into the PS16 pattern. The format of a pattern is this: Byte Name Description ────── ─────────────── ──────────────────────────────────────── 0-1 Size (Word) Size is the total size of the ENTIRE pattern, INCLUDING bytes 0 through 2. This number is paragraph aligned. This means that if a pattern is 253 bytes long, its actual size is 256. If the size is 256, no change takes place. 2 NumLines (Byte) This is the number of pattern lines in the pattern. If a pattern only uses 30 lines and the pattern must terminate to the next pattern at this point, store a 30 here. Otherwise, ALWAYS store a 64 so the entire pattern will play. 3-?? Track This is Track 1, terminated with a -1. The other tracks follow immediately after this. See routine MOD_LoadSavePatterns in MODLOAD.ASM. ╒══════════════════════════════════════════════════════════════════════════════╕ │ PS16 Sample Format, Version 0: │ ╘══════════════════════════════════════════════════════════════════════════════╛ Only the digital sample format has been defined thus far. In order to appeal to archivers more, the sample storage format has changed. Instead of being stored as raw data as in all trackers I am aware of, the format was changed to use "deltas." The algorithm for converting a sample to deltas is: Get the number of sample bytes to process. Call this SamplesLeft. Set Delta counter to 0. DO Get a byte from the buffer. Store the byte in Temp. Subtract the Delta counter from the byte. Store it in the buffer. Move the Temp byte into the Delta Counter Decrement SamplesLeft. WHILE(SamplesLeft <> 0) See routine MOD_ConvertSample in MODLOAD.ASM. The technique for conversion back to the raw data is: Get the number of sample bytes to process. Call this SamplesLeft. Set Delta counter to 0. DO Get a byte from the buffer. Add onto the byte the Delta Counter. Store the byte in Delta Counter. Store the byte in Temp. Decrement SamplesLeft. WHILE(SamplesLeft <> 0) ╒══════════════════════════════════════════════════════════════════════════════╕ │ PS16 Comment Format, Version 0: │ ╘══════════════════════════════════════════════════════════════════════════════╛ This format resembles an ILBM format. Only two things are currently defined in this format. Signature Description ───────── ───────────────────────────────────────────────── INST Immediately following this four character identifier is a byte indicating the length of each instrument name. After that is a byte describing how many samples names are stored in this text. Example for the MOD format: I N S T [Chr 22] [Chr 2, normally 31] [Instrument name #1 padded to 22 chars] [Instrument name #2 padded to 22 chars] See MOD_ConvertComments in MODLOAD.ASM. TEXT Immediately following this four character identifier is a WORD describing the length of the upcoming text.